IMPORTANT: Staring from version 11.7, when Automations and Collection Extensions are configured to Run As User (Windows only), the script executes in a temporary directory under the user's AppData folder instead of the action distribution directory. This security enhancement prevents relative paths from working reliably. If your script loads the SysTrack PowerShell module (SysTrackPS.dll) or references other files outside your action package, you must use absolute paths or registry-based path resolution.

Loading SysTrack PowerShell Module in User-Context Scripts

If your Collection Extension or Automation uses SysTrack PowerShell cmdlets, replace relative path imports with the following registry-based resolution pattern:

Old Pattern (No Longer Supported in 11.7+):

Copy
# This will FAIL when running as User in version 11.7+
import-module -name "..\..\..\Utilities\SysTrackPS.dll"

New Pattern (Required for 11.7+):

Copy
# Load SysTrackPS module.
$node = ('WOW6432Node','')[${env:PROCESSOR_ARCHITECTURE}.StartsWith('ARM')]
$regPath = “HKLM:\\SOFTWARE\$node\Lakeside Software\Deploy”
$lsiPath = (Get-ItemProperty -Path $regPath).InstallDir
$dllPath = “$lsiPath\Utilities\SysTrackPS.dll”
if (!(Test-Path $dllPath)){break}
Import-Module -Name “$lsiPath\Utilities\SysTrackPS.dll”

Why This Works: The registry lookup retrieves the actual installation directory of the SysTrack Agent, ensuring the script can locate SysTrackPS.dll regardless of where the action executes.

NOTE: This change only affects scripts running as User. Scripts running as System continue to execute in the action distribution directory, but the registry-based pattern is recommended for consistency.

Files Within Your Action Package

Relative paths between files inside your action package still work normally. For example, if your action contains MyScript.ps1 and config.txt, you can still use:

Copy
$config = Get-Content ".\config.txt"

Only references to files outside the action package (like SysTrackPS.dll) require absolute paths or registry resolution.